Service providers use Metropolitan Area Networks (MANs) to provide customers with connectivity to the Internet and/or with connectivity to geographically diverse customer locations. Historically, MANs have been implemented using Synchronous Optical Networks (SONET), Frame Relay, or Asynchronous Transfer Mode (ATM) technologies. Recently, however, service providers have begun to use Ethernet technology to implement MANs. These Ethernet-based MANs are referred to as Metro Ethernet Networks (MENs).
Often, service providers implement Metro Ethernet Networks using devices, such as Ethernet switches, that provide purely Layer 2 (also referred to as data-link layer) functionality (as opposed to using routers or other devices that also perform Layer 3, or network layer, functions). In Ethernet networks, Layer 2 functionality includes the ability to forward messages based on the messages' Media Access Control (MAC) destination address and Virtual Local Area Network (VLAN). Ethernet devices that provide Layer 2 functionality “learn” that messages addressed to certain MAC addresses should be sent via certain interfaces. If an Ethernet device receives a message having an unknown MAC address (i.e., a MAC address that has not yet been learned by that Ethernet device), the Ethernet device will flood the message from all of the Ethernet device's interfaces in the incoming VLAN (i.e., the VLAN in which the message was received).
Network devices that perform Layer 2 Ethernet forwarding (as opposed to both Layer 2 and Layer 3 forwarding) flood messages with a multicast Media Access Control (MAC) address to all interfaces in an incoming VLAN. For example, the range of multicast MAC addresses is typically excluded from the range of addresses that an Ethernet device will learn, and thus the Ethernet device will not learn multicast addresses. Because of this, the Ethernet device will handle a multicast message as if the destination of that message was unknown. Accordingly, multicast messages are flooded throughout the appropriate VLAN in the Metro Ethernet Network.
Flooding multicast messages creates an inefficient use of resources within the Metro Ethernet Network. For example, if fewer than all of the User Network Interfaces (UNIs) within the Metro Ethernet Network are connected to receivers for a particular multicast flow, flooding messages in that multicast flow will cause a UNI that does not have receivers for that multicast flow to nevertheless flood multicast streams to an attached customer edge (CE) device, wasting both bandwidth on the link and processing cycles in the CE device.
When Ethernet Virtual Connections (EVCs) are implemented within a MEN, a flooded message is only flooded within the EVC of the interface via which the message was received into the MEN. However, even though this may shield uninterested devices in other EVCs from multicast messages being flooded in that EVC, inefficiencies can still arise within the EVC in which the multicast messages are flooded. Additionally, if several CE devices are connected by a multipoint-to-multipoint Ethernet Virtual Connection (EVC) within the Metro Ethernet Network, and if some CE devices are connected at different speeds, CEs connected at lower speeds can be overwhelmed by multicast flows that the lower-speed customer edge devices are not interested in receiving. For example, assume an EVC having UNIs connected to three CE devices. Two of the CE devices have 100 Mb/s (Megabit per second) connections while the third CE device has a 10 Mb/s connection. If a multicast flow is being transferred between the two CE devices having the 100 Mb/s consumes more than 10 Mb/s, the lower-speed CE device with the 10 Mb/s connection may even be unable to use its connections to the Metro Ethernet Network. As this example shows, improved techniques for handling multicast messages are desirable.